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The Amateur Radio Packet Network has implemented an ad-hoc, 
hierarchical, area-based message addressing system. In the United States 
these areas resolve down to states or local domain. Packet Bulletin Board 
Systems (PBBSs) also support a limited user directory service, implemented 
as the “home BBS” function. This sets the stage for relatively easily 
implementing a distributed directory service for the packet network. 


The Problem 


It isn’t easy to ensure that a packet message will reach its intended recipient. There 
is no universal, automated system to keep track of which Amateurs are receiving 
their packet “mail” at which PBBS. (Yes, there are White Pages servers, but their 
operation is neither universal nor automatic.) Originators must both know and 
explicitly specify the destination PBBS when sending a message if it is to have a 
reasonable chance of being received. 


There are exceptions which at times make it easier to send packet messages. PBBSs 
can automatically address messages when they “know” the “home BBS” of the 
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addressee. Some systems can query White Pages servers to determine the correct 
destination PBBS. However, these are exceptions to the situation. facing most 
packet users. 


A Proposed Solution 


Consider the situation if all PBBSs “know” where to send messages addressed to all 
active packet operators in their area. Amateurs could then easily correspond with 
others in their area without having to know which system they frequent. If one 
wanted to send a message to an Amateur in a distant state or province the 
“address” need only consist of the destination state or province; upon reaching the 
first PBBS in the destination state or province it would be re-addressed to the 
correct PBBS. 


This can be accomplished with a modification to the “home BBS” function of 
Packet Bulletin Bohrd System software and establishment of state/province (or 
sub-area) area “flood” message distribution. 


As currently implemented the “home BBS” function requires manual updates, and 
operates in what seems to be a “backwards” manner. Users must connect with as 
many PBBSs as possible and inform these systems of their preferred “home BBS.” 
If users change their preferred “home” they must again connect to each system to 
update the information. 


It would be much more logical for users to connect to their system of choice and 
declare it to be their “home BBS.” PBBSs would share “home b’bs” data within 
their area. All systems within the state/province, or sub-area, would know the 
“home bbs” of all active packet operators in their area. 


Consideration must be given to dealing with packet operators who move from one 
area to another. As part of the procedure to declare a PBBS as one’s “home,” the 
user must be asked for the callsign of their previous “home BBS.” The previous 
“home,” and all systems in its area, must also be advised of the new “home BBS” 
declaration. 
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Another special case is temporary operation. Many Amateurs travel. Some live in 
different areas throughout the year. This requires the ability to declare a system to 
be one’s temporary “home BBS.” 


Update messages should be allowed to contain multiple updates, but each 
individual entry must be date/time-stamped. This will permit checking that update 
information is truly new, and not an old message which was delayed or re-sent for 
some reason. In addition there should be fields for optional inclusion of effective 
and expiration dates. This will provide for advanced scheduling of “home BBS” 
changes for “migratory” users. 


Proposed PBBS Dialogues 


The following is a proposed dialogue for PBBSs to use for the new implementation 
of “home BBS”: 


@KB7UV MailBox> 
home 


Your home BBS is the PBBS where you will receive yourpacketmail. 
If you choose this as your home BBS system*ALL* packetmessages 
for you will be routedhere. You can only have one home BBS. 


Your current home BBS is WB2GTX. 
{Youdonotcurrentlyhave  ahome BBS. i? 


Change home BBS to KB7UV? [Y/N/?] 


< 
This is now your home BBS. All yourpacketmailwillbe forwarded 


to this system. 
@KB7UV MailBox> 


‘If there was no “home bbs” information on file for the user. 
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For both temporary operation and permanent changes to other areas, Amateurs 
who know which system will become their new home (permanent or temporary) 
should be able to inform their current home system of the change. This dialogue 
could be similar to this: 


@KB7UV MailBox> 
nothome 


{This systemis not your "home" BBS -- cannotprocess "nothome" 
request. @KB7UV MailBox>}? 


You are currently receiving yourmailhere. Do youwishto change 
to another BBS [Y/N] ? 


Y 

What is the callsign of the BBS you wish to change to? 
WIAW 

{W1AW does not appear in the "known BBS" list. In what 
state/province (Z-letters) is it located?}° 


You have chosen W1AW.CT.USA as your new home BBS. Is this correct 
[Y/N]? 

Y 

Your home BBS change to W1AW.CT.USA has been accepted. W1AW and 
all EBSs in CT will be informed of yourmove. 

@KB7UV MailBox> 


Message Routing 


*This would be the response if the user attempted to use this command on a PBBS 
other than their “home bbs.” 


*This prompt would be sent if the specified new “home” was not “known” to the 


PBBS. The state is needed in order to route the automatically generated update message 
to the specified new “home” system. Following the query for state the PBBS should ask 


for the country of the new “home BBS.” 


48 


Whenever a message arrives at a PBBS the system will first look to see if it already 
fully addressed for another destination PBBS. If so the addressing will be left 
alone, and the message will be forwarded out based upon that address. This 
ensures that messages fully addressed upon origination will not be “tampered” with. 


If an arriving, or originated, message is not fully addressed whatever routing 
information it does carry will be checked. If it is for another area it will be 
forwarded as specified. If it is for the same area as the PBBS, or if it has no 
routing information, the PBBS will check to see if the addressee is “known.” For 
“known” addressees the system will either readdress and forward the message, or 
hold it for pick-up, as appropriate. Messages for “unknown” addressees without 
routing information are more of a challenge. 


The first check of these “unknown” messages should be of the callsign prefix of the 
addressee. Foreign callsigns are rather easy: route the message to the appropriate 
country.’ Domestic callsigns can be automatically looked-up through a nearby 
White Pages server for routing information, if available, or through a callbook 
server to obtain the addressee’s state or province. Messages for which routing was 
found at the White Pages server will be sent as specified. Out-of-state/province 
messages, looked-up through a callbook server, should then be forwarded to the 
correct states or province. Messages with instate/province addressees which are not 
known to the White Pages Server, and those whose addresses could not be found at 
all, require special handling. 


If there are sub-areas within the state/province, an inquiry should be sent to those 
other sub-areas to see if the addressee is known. If a reply is received with routing 
information the message should be re-addressed and forwarded. If no routing 
information is received within a specified time period (seven days seems reasonable) 
the message should be returned to the sender as “undeliverable, addressee 
unknown.” 


‘Many amateurs operate under reciprocal agreements. The six-character “To:” field 
does not provide for portable designations... This common PBBS software limitation 
must be rectified. 
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Why Not Dedicated Servers? 


Others have suggested utilizing dedicated Directory Servers for the Amateur Packet 
Radio Network. These schemes would require address queries and responses for 
each message to be forwarded. Without higher speeds this will further burden our 
already heavily trafficked networks. Distributing directory information among 
message servers will limit these queries and responses to those messages destined for 
other areas. 


This is not to say that dedicated Directory Servers wouldn’t be helpful along with 
this proposal for distributed directory services. Dedicated servers in all areas, 
sharing information, would provide a more efficient means for dealing with 
unknown addressees. 


Implementation 


As current BBS software already supports the “home BBS” function, albeit in what 
seems to be a backwards implementation, it should be relatively easy for this 
distributed directory service proposal, or something similar, to be implemented. 
This paper outlines needs and a proposed solution; the actual implementation will 
need to be a cooperative effort by the PBBS software authors. 


There is an additional requirement for this to work. Each state/province, and any 
sub-areas, must establish area flooding forward routes. All PBBS systems will need 
to be able to forward messages addressed simply as “@2ZT” where “CT” is a Z-letter 
state/province designation. In this way update messages can be sent to 
“UPDATE@ZT,” “WPAGES@XT,” or similar for automatic distribution to all 
PBBSs and White Pages servers in the region. 


Remote Operation Message Formats 


- Home Declaration 
header: SP UPDATE@ZT <BBSCALL $123456.BBSCALL 
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title: | not used — blank or informative, such as: “New Users 
This System” 

text: one or more line of the following: 

“callsign YYMMDDHHMM [START-DATE EXP DATE]” 

Where “YYMMDDHHMM’" is a date/time stamp 
indicating when the user made the “home bbs” declaration, 
and START_DATE and EXP DATE are optional fields of 
the format YYMMDD for effective and expiration dates. 


Note: The “home bbs” for the callsigns in the message is the 
originating PBBS as shown in the header. Use of RFC-822 
headers is suggested so as to place this information explicitly in 
the body of the message. 


. Callsign Look-up Request To Address Server 


header: SP LOOKUP@ServerCall <BBSCALL 
$123456_BBSCALL 
tite: REQSTATE 
text: one or more line of the following: 
“call sign” 


. Response From Address Server 


header: SP DAEMON@BBSCALL <ServerCall $34567_ServerCall 
tile: RE:REQ STATE 
text: one or more line of the following, as appropriate: 
“Callsign Address” 
“Callsign ***NOT FOUND***” 


Where Address is in one of the forms: 
“YT.cou” 
“bbscall. £T.cou” 


(“ZT” — 2-letter state/province code) 
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